Various systems exist for broadcasting a live or pre-recorded video stream over the Internet. These conventional systems, however, have numerous drawbacks.
For example, in conventional systems, broadcast devices cannot be controlled remotely when the devices are situated behind a user's firewall.
One attempt to address this drawback involves configuring the user's router to give access to the broadcast device. This approach involves, for example, creating or otherwise exploiting a “hole” in the firewall, such as by forwarding Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) ports to the broadcasting device so that the user could use Hypertext Transfer Protocol (HTTP), SSH, Remote Procedure Call (RPC), or the like to control the broadcasting device remotely, or designing the user's network to include a demilitarized zone (DMZ), wherein the broadcast device is placed in the DMZ so it can be controlled remotely. This approach, however, requires technical expertise that the average user may not possess. Furthermore, this approach also exposes the broadcast device to unauthorized and/or malicious use by allowing others to potentially access the broadcast device behind the firewall. For example, the broadcast device could be subject to denial of service attacks, rendering the device useless or otherwise ineffective. Further still, certain broadband routers/firewalls do not allow broadcast streaming, wherein users with these routers/firewalls installed often have no way of knowing that this is the reason they cannot broadcast.
Another attempt to address this drawback involves installing a virtual private network (VPN) relay server. Again, this approach requires a degree of technical expertise that the average user may not possess, and is often performed by an information technology (IT) specialist. Furthermore, the VPN server and software are expensive, which may present a cost barrier to implementation for many users. Additionally, this approach requires that VPN credentials be maintained between VPN clients and VPN servers, which adds complexity and overhead. As noted above, because certain broadband routers/firewalls do not allow broadcast streaming, users with these routers/firewalls installed often have no way of knowing that this is the reason they cannot broadcast.
Yet another attempt to address this drawback involves controlling the broadcast device on-site (i.e., not remotely). This approach, however, requires that an administrator or other authorized user be on site to control the broadcast device. Additionally, if the administrator delegates someone else to control the broadcast device, there is a risk that the person may knowingly or unknowingly alter the desired configuration, given the complexity of setting the proper broadcast parameters. As noted above, because certain broadband routers/firewalls do not allow broadcast streaming, users with these routers/firewalls installed often have no way of knowing that this is the reason they cannot broadcast.
As another drawback of conventional broadcasting systems, the broadcasting systems utilize a broadband connection (for network traffic) that provides an insufficient or otherwise poorly sufficient upload speed.
One attempt to address this drawback involves using broadcast software running on a general purpose computer to compress the video before transmitting it. However, if the broadcast device is the general purpose computer, the computer may not be powerful and/or fast enough to effectively perform the compression and transmit the video. Computers that are powerful and fast enough to perform the compression and transmission are likely to be expensive, which may present a cost barrier to implementation for many users. Additionally, users are required to spend time and/or money to purchase, download, install, and maintain the compression software. Furthermore, the broadcast software may require a steep learning curve of its users. Since the average user does not know how the broadcast software functions work and/or which settings are important in the broadcast software, the user may become frustrated and/or waste a significant amount of time.
Another attempt to address this drawback involves using dedicated broadcasting hardware. Such dedicated hardware is likely to be expensive, which may present a cost barrier to implementation for many users. Furthermore, the hardware may require a steep learning curve of its users. Since the average user does not know how the broadcast software functions work and/or which settings are important for the hardware, the user may become frustrated and/or waste a significant amount of time.
As yet another drawback of conventional broadcasting systems, the broadcasting systems may not adequately prevent unauthorized access to the video being broadcast. Users often want broadcasts to be viewable only by certain viewers to control privacy and/or insure that paid broadcasts cannot be stolen or otherwise misappropriated.
One attempt to address this drawback involves security through obscurity. For example, when an event is being promoted through an e-mail or similar invite, the e-mail includes an invitation link containing a long complex web address having enough complexity such that the chance of guessing the link becomes acceptably small. However, when a viewer prints out the e-mail invite, the process of typing in the long complex web address is onerous and it is very difficult for the viewer to accurately type in the long complex web address. Consequently, the viewer is apt to become frustrated and to forego accessing or otherwise viewing the video.
Another attempt to address this drawback involves authenticating a viewer requesting access to an event by requiring a username and password. However, if any unauthorized viewers obtain these credentials, then the unauthorized viewers and/or anyone else they provide the information can view the video being broadcast for the event. Additionally, even without obtaining the credentials, an unauthorized viewer situated between a video player for playing the video and a media server for providing the video could “sniff” for the video data (i.e., the video stream) as it is transmitted from the media server to the player. In this manner, the unauthorized viewer could view the video stream without anyone else knowing.
As still another drawback of conventional broadcasting systems, an event to be broadcast may be so popular that a server delivering the video of the event reaches its capacity or breaks, such that viewers that want to view the video cannot.
An attempt to address this drawback involves using a content delivery network (CDN) to provide the ability to service any size event. However, in using the CDN, overall capacity may not be dynamically adjustable. Accordingly, an administrator may be forced to set a predefined limit on the capacity, which results in either wasted server capacity or rejecting certain viewers who wish to view the video.
As another drawback of conventional broadcasting systems, the broadcasting systems require someone to be on-site to turn the camera on and off for an event to be broadcast. No known attempts have been made to address this drawback.
The general inventive concepts contemplate systems, methods, and apparatuses for use in scheduling and otherwise carrying out the autonomous broadcasting of video data. Exemplary embodiments of the general inventive concepts, including those disclosed herein, may or may not address one or more of the aforementioned drawbacks and/or any other drawbacks of conventional broadcasting systems.